Size Change: +5.35 kB (0%)

Total Size: 1.29 MB

_{compressed-size-action}

Thank you for working on this! 🎉

Even in this state: click-through and list view management, it feels like the potential is there. Here's a GIF:

A few notes:

• Drag and drop doesn't appear to work entirely correctly.
• Can "Manage menus" exist inside the menu selection dropdown?
• Selecting a menu item doesn't select it in the canvas. This is intentional as otherwise it would put focus there and the inspetor would be replaced. But maybe the selection style should be different, perhaps black instead of blue. Nothing to block this PR, just thinking out loud.
• Perhaps a question for @jameskoster — I can't recall the latest on clickthrough. When I select a template with clickthrough, there's a blue overlay. There isn't in this branch when I select the menu. Should there be?

I'm missing the "Create new item" button, which is going to be the next tricky step to solve. The basic idea is to let you build the entire menu, including sorting, moving into submenus, etc., in this panel alone. I imagine a simple way to start is that this would insert a Page Link with the dropdown open, this one:

Would that be possible/feasible?

Perhaps a question for @jameskoster — I can't recall the latest on clickthrough. When I select a template with clickthrough, there's a blue overlay. There isn't in this branch when I select the menu. Should there be?

The overlay appears only on hover at the moment, because once the parent is selected all the child-blocks can be manipulated.

If we pursued something like #43608, then the overlay would persist upon selection as well.

Good points, thanks for responding. The main issue to solve here is to ensure a great navigation building experience that lets you use the inspector interface with the main navigation block selected, to build out your entire menu.

The tricky balance to find here, is one of not directly locking the canvas view from being edited there, but nudging towards the ergonomics of the list view. Perhaps something like the recently landed "content lock" can be employed here? (Here are some GIFs) — I know that's designed for patterns, but can that be turned on by default for navigation?

templateLock:contentOnly would theoretically allow folks to change link labels and destinations, but not re-order, add, or delete. I'm not sure that's a great fit for navigation, but I suppose it depends on which on-canvas actions we want to allow.

Perhaps something like #43608 could work. IE:

• Selecting a menu doesn't immediately unlock any edit-ability.
• Clicking the List button in the toolbar would toggle the visibility of the Inspector (and list view therein).
• A separate "Edit" button (either in the toolbar or ellipsis menu) could temporarily unlock full on-canvas edit-ability.

templateLock:contentOnly would theoretically allow folks to change link labels and destinations, but not re-order, add, or delete. I'm not sure that's a great fit for navigation, but I suppose it depends on which on-canvas actions we want to allow.

We'd still have the full "Modify" action (which btw can move to the ellipsis), and we would pair it with the inspector interface for building and adding to the menu.

I suppose we can try it, but I think it might be strange if it's possible to edit menu labels, but not add links or move things around 🤔

A full-lock-with-easy-unlock feels like a better approach to me, similar to what we've explored for template parts.

I suppose we can try it, but I think it might be strange if it's possible to edit menu labels, but not add links or move things around 🤔

This would work in the list view no?

I don't have a strong opinion, honestly. What I believe to be key here is:

a) building your navigation block in the canvas needs work still
b) for the 80% of use cases, a simpler interface is likely going to be an inspector tree-view, reminiscent of the old menu editor

b mainly works if you don't lose your place every time you select different menu items in the canvas.

Based on followup in the original issue this PR will move forward with attempting a customization of the list view to support opting out of canvas selection of blocks. We can merge it then just like that.

I will make it a gutenberg experiment from the start considering how many iterations will take before the off canvas editing is really good enough UX.

I'll try to move this forward in an experimental way where I copy the items I change so that iterations can land independently of trunk versions. For instance I'll see if making a copy of ListView in the nav block works and the same for other things that don't work out of the box for the requirements of off canvas editing.

What's the best way to test this? I'm not seeing any changes in the nav inspector just diving in now.

I remain convinced that this sliding inspector editing interface for child blocks be immensely useful for the navigation block, potentially letting us reach a point of usability that reduces the pressure on all the separate rough edges the project has uncovered. Not just that, but it will also be useful for social links, buttons, content-only editing containers, and more. It has such potential, let me know any way we can help push this forward! CC: @WordPress/gutenberg-design

What's the best way to test this? I'm not seeing any changes in the nav inspector just diving in now.

@jasmussen go to Gutenberg > Experiments and check this experiment on.

I remain convinced that this sliding inspector editing interface for child blocks be immensely useful for the navigation block,

I am too since eons ago #13690 (comment) I've been dreaming of a structured way to manage menus :D

Although this is approved I will close it and follow up with four PRs: to make it easier to keep track of what it was done:

1. PR to make the experiment available
2. PR to add the duplicated list view
3. PR to PR to add the new list view prop in the duplicated comp and add the duplicated list view to the navigation block to use the new prop
4. PR to move the navigation selector in the experiment